Digital Rights Management (DRM) is a system technology for protecting and managing rights on digital contents, and provides a series of protection and management systems for the process of an illegal copy prevention of contents, acquisition and distribution of a Rights Object (RO) associated with DRM contents, and production and consumption of DRM contents.
FIG. 1 is a view illustrating a general configuration of a DRM system.
A typical DRM system manages digital contents from a contents provider to be used as much as the Rights Object granted to the user. The contents provider is an entity corresponding to a content issuer (CI) 10 and/or a Rights Issuer (RI) 20.
The content issuer (CI) 10 issues a content (hereinafter, referred to as “DRM content” or “digital content”) protected by using a specific encryption key to protect the contents from the unauthorized user, and the Rights Issuer (RI) 20 issues a Rights Object that is required for using the DRM contents.
The device 30 includes a DRM agent 40, and the DRM agent 40 receives a DRM content from the content issuer (CI) 10, and receives a right in the form of a Rights Object (RO) which is associated with the contents from the Rights Issuer (RI) 20. The DRM agent can store the Rights Object (RO) into a memory card or a secure removable media (SRM) 50 via an SRM agent 60 included in the SRM 50.
Afterwards, the DRM agent 40 interprets permissions and/or constraints included in the Rights Object (RO), thereby managing the usage of the DRM content in the device 30 and the SRM 50.
The permissions and/or constraints that have been set once in the Rights Object need to be changed as circumstances change. Therefore, a method of adding and/or changing the permissions and/or constraints, that are included in the Rights Object (RO) stored in the SRM 50, is required; in other words, a method of upgrading the Rights Object (RO) in the SRM 50.
For the understanding of the related art and the present invention, hereinafter, the terms used in this specification will be briefly defined in the following Table 1.
TABLE 1TermDefinitionDRM AgentAn entity in the device that manages permission to media objects onthe device.Media ObjectThe Media Object is a digital work. For example, a ringing tone, ascreen saver, a Java game or a composite object, etc. are included inthe media object.PermissionThe Permission is actual usages or activities allowed (by the RightsIssuer) over DRM Content.DRM ContentThe DRM Content is media objects consumed according to a set ofauthorization in the Rights Object.Secure AuthenticatedThe Secure Authenticated Channel is a logical channel forChannel (SAC)communication that provides message integrity and confidentiality.RightsThe Rights are the collection of permissions and constraintsdefining under which circumstances access is granted to DRM content.For the purposes of this document, Rights consist of a Rights Object, itsassociated state, and other related information.Rights Issuer (RI)The Rights Issuer is an entity that issues Rights Objects to OMADRM conformant devices.HandleThe handle is A random value generated by the DRM agent, whichis stored in the SRM and in the Operation Log (kept in the Device) usedfor associating the DRM agent to specific right for the Move or LocalRights Consumption operation.When transmitting a message for using or moving the rights (orRights Object (RO)), the DRM agent generates the handle and transmitsthe generated handle to the SRM.Mutual AuthenticationThe Mutual Authentication and Key Exchange includes the steps ofand Key Exchangeauthentication request/response and key exchange request/response(MAKE)between entities. Once the MAKE is completed, a SAC context isgenerated for SAC. Specifically, during the MAKE procedure, the DRMagent and the SRM agent negotiate trust model, entity ID and securityalgorithm, and mutually authenticate each other and exchange keys(session key and MAC key) for the protected communication thoughSAC.Rights MetaDataThe Rights MetaData includes a Rights Object version, an alias ofthe Rights Object (RO Alias), an identifier of the Rights Issuer (RIIdentifier), an address of the Rights Issuer (RI URL), an alias of theRights Issuer (RI Alias), and a time stamp of the Rights Issuer (RI TimeStamp).Rights Object (RO)The Rights Object is also referred to as use rights, including apermission (or constraint) to DRM contents and other attributesconnected to the contents.The Rights Object may be typically stored in a device, but may bealso stored in a memory card, for instance, SRM. The Rights Object maybe stored in the form of a Rights Object Container in SRM.Rights ObjectThe Rights Object Container is one of the forms for storing theContainerRights Object. The SRM agent considers the Rights Object Container asan opaque object. In other words, the SRM agent does not parse theRights Object Container.The Rights Object Container includes a <rights> element and a<signature> element.State InformationThe State Information denotes a current state of each statefulpermission within stateful use rights (for instance, remaining count,interval, start date, etc.). If the usage rights are stateful, then the StateInformation is included in rights.Rights InformationThe Rights Information includes Rights MetaData, a Rights ObjectContainer, and the State Information.The Rights Information has an information structure for including theRights MetaData, the Rights Object Container, and the State Information.Also, it may be configured with a hierarchical structure, such as XML.Rights ObjectThe Rights Objects Encryption Key is an encryption key for RightsEncryption Key (REK)Object, and has a binary form, namely, no base64 encoding.Asset IdentifierThe Asset Identifier is included in a Rights Object and used to(AssetID)identify DRM content.A Rights Object may be associated with a plurality of the assetidentifiers. The plurality of the asset identifiers may be included in theRights Object in the form of a list of the hashed values which is called asa list of hashed asset identifier (LAID).In addition, the plurality of Rights Object (RO) associated with thesame content may have the same AssetID, respectively.SAC ContextOnce a SAC has been established, a logical SAC context will exist.The SAC context exists until a new SAC with the same Device andSRM, under the same trust model, is established.By using a pair of SRM Hello messages, the DRM agent maydetermine whether it communicates with the same SRM. If the DRMagent reuses the SAC context, and sends a secure message to receivea Field Integrity Verification Failed error, it indicates that the SAC contextis no longer effective. The DRM agent should establish new SAC.The context maintains information as illustrated in the followingTable 2.
In the above Table 1, information required to configure the SAC context may include the items enumerated in the following Table 2.
TABLE 2NameDescriptionMAC KeyA Message Authentication Code key used for integrity ina SAC session between the DRM agent and the SRM agent.Session KeyAn encryption key used for confidentiality in aSAC session between the DRM agent and the SRM agent.SelectedAlgorithms negotiated through the MAKE procedure.AlgorithmsTrustUnder a certain trust anchor, multiple SACs can beAnchorestablished. If the trust anchor is switched, the device needsto establish another SAC.Entity IDIndicates a SRM ID for the device (under a trust anchor)and a device ID for the SRM (under a trust anchor).
The SRM 50 may store the Rights Object (RO) as illustrated in Table 3.
TABLE 3HandleRights InformationLAIDREK
In other words, the SRM 50 may include the handle, the Rights Information, the LAID, and the REK.
In the above Table 1, the Rights MetaData and Rights Object Container may include the elements as illustrated in the following Table 4.
TABLE 4Rights MetaData{circle around (1)} Rights Object Version: <protectedRO> element::<ro>element::<version> element.{circle around (2)} RO Alias: <protectedRO> element::<ro>element::<roPayloadAliases>::<roAlias> element.{circle around (3)} RI Identifier: <protectedRO> element::<ro> element::<riID> element.{circle around (4)} RI URL: <protectedRO> element::<ro> element::<riURL> element.{circle around (5)} RI Alias: <protectedRO> element::<ro> element::<roPayloadAliases>element::<riAlias> element.{circle around (6)} RI Time Stamp: <protectedRO> element::<ro> element::<timeStamp>element.Rights Object Container{circle around (1)} <rights> element: <protectedRO> element::<ro> element::<rights>element.{circle around (2)} <signature> element: <protectedRO> element::<ro>element::<signature> element.
In the above Table 4, the symbol “::” indicates a sub-element under a specific element. For example, the <protectedRO>::<ro>::<version> element indicates a <version> element which is a sub-element of the <ro> element under the <protectedRO> element. FIG. 2 illustrates the <protectedRO>::<ro>::<version> element.
In order to upgrade a certain Rights Object (RO), it should be able to find the Rights Object among the Rights Objects stored in the SRM 50 using the identifier of the Rights Object, for instance, roID. The roID uniquely identifies the Rights Object, and it may be a <uid> element in the Rights Object. The <uid> element may exist within a <context> element which is a child element of the <rights> element in the Rights Object.
The <uid> element may be included in a hierarchical structure such as XML. Considering the limited computing capability, the SRM 50 may not be able to directly access an element in a complicated XML format. In order to find a Rights Objects corresponding to the given roID, the SRM 50 needs to retrieve the <uid> element of the Rights Object and check whether the <uid> element of a Rights Object matches the roID. However, the SRM 50 may not be able to parse the Rights Object in XML format due to the limited capability. Therefore, for instance, the SRM 50 transmits the Rights Object to the DRM agent 40 so that the DRM agent 40 with relatively strong capability can access the <uid> element in the transmitted Rights Object.
FIG. 3 illustrates an example of a searching procedure for a SRM rights upgrade, where the DRM agent 40 searches rights stored in the SRM 50 for the right to be upgrade. Hereinafter, the procedure will be described in detail with reference to signal flows illustrated in the drawing.
1) The DRM agent 40 becomes aware of the identifier of the Rights Object subject to be upgraded and upgrade information such as permissions and/or constraints via e.g. an upgrade trigger message from the RI 20 (S110). Then, prior to searching Rights Objects stored in the SRM 50, the DRM agent 40 checks whether any Rights Objects stored in the device 30 have a Rights Object identifier (RO ID) that matches the Rights Object identifier included in the upgrade trigger message (S112).
For instance, the DRM agent 40 may access the <uid> element of the Rights Objects, respectively, and find the <uid> element which has the same value as the Rights Object identifier.
If the DRM agent 40 find no Rights Objects in the device 30 that matches the Rights Object identifier, then the DRM agent 40 starts to search Rights Objects stored in the SRM 50.
2) The DRM agent 40 transmits to the SRM agent 60 a handle list query request message, for instance, Handle List Query Request message, which is a request for a list of all handles of rights in the SRM 50 (S114).
The handle list query request message may include the parameters as illustrated in the following Table 5.
TABLE 5FieldDescriptionLAIDList of AssetID of the contents associated with the(with number of Hrights. The number of H (AssetID) is set to “0.”(AssetID) = 0)Handle List LengthMaximum length of the handle list that the DRMagent desires to receive per message.
3) Upon receiving the handle list query request message, the SRM agent 60 processes the request, and transmits a handle list query response message, for instance, Handle List Query Response message, to the DRM agent 40 (S116).
The handle list query response message may include the parameters as illustrated in the following Table 6.
TABLE 6FieldDescriptionStatusIncludes a processing result of the handle list query request.Handle ListList of handles stored in SRMContinuation‘True’ if the Handle List in this response is a part of theFlagwhole Handle List and there are subsequent parts of it, andotherwise ‘false’. So if ‘true’ more handle list should bereceived afterwards.
4) The DRM agent 40 receives the handle list query response message and checks the handle list (S120). The DRM agent 40 needs Rights Information for each handles in the handle list, so requests each Rights Information in the subsequent steps.
5) The DRM agent 40 transmits to the SRM agent 60 a rights information query request message, for instance, Rights Information Query Request message, which is to obtain the Rights Information corresponding to the handle (S122a).
The rights information query request message may include the parameters as illustrated in the following Table 7.
TABLE 7FieldDescriptionHandleHandle that identifies the rights in the SRM whose RightsInformation will be transferred
6) The SRM agent 60 receives the rights information query request message and checks whether the SRM has the right requested by the message. If so, the SRM agent 60 transmits to the DRM agent 40 a rights information query response message, for instance, Rights Information Query Response message, which includes the Rights Information of the right (S124a).
The rights information query response message may include the parameters as illustrated in the following Table 8.
TABLE 8FieldDescriptionStatusIncludes a processing result of the handle listquery request.Rights MetaDataDescribed in the above Table 1Rights Object ContainerDescribed in the above Table 1State InformationDescribed in the above Table 1
7) Next, if one or more handles are included in the handle list, the DRM agent 40 repeats the above-mentioned steps 5) and 6) to obtain Rights Information of all the handles (S122b and S124b).
In other words, as illustrated in the dotted line in FIG. 3, the DRM agent 40 and the SRM agent 60 exchange the rights information query request message and the rights information query response message for each handles in the handle list.
8) The DRM agent 40 compares each Rights Information that have been received from the SRM agent 60 with the Rights Object identifier included in the trigger (S130) to find the rights to be upgraded. For instance, the DRM agent 40 checks whether the <uid> element in the Rights Information is same as the Rights Object identifier.
The DRM agent 40 can, by selection, load all information of the right stored in the SRM 50 beforehand for the search for the right to be upgraded.
As described above, the method of upgrading a Rights Object according to the related art has problems that the DRM agent 40 should exchange plenty of messages to acquire the information on the rights stored in the SRM 50 and in the worst case the DRM agent 40 should search for the right to be upgraded exhaustively among all the Rights Object stored in both the device 30 and the SRM 50. Particularly, it is more problematic that, in the first place, Rights Objects stored in the SRM 50 should be transferred to the device 30 for the search.
In addition, the method of all the Rights Information in the SRM 50 being transferred into the device whenever the SRM 50 is inserted into the device 30 is problematic, as it may not be always feasible due to limited storage space in the device 30 and time constraint.